|
How to update a language file
I noticed one has to know a few internals before he's able to update a language file. Quelsaruk helped me with the first steps this afternoon, thanks to him.
Creating new languages
If you want to create a new language, just follow this description: http://rockbox.haxx.se/mail/archive/rockbox-archive-2002-09/0856.shtml
Prerequisites to be able to translate
To avoid manual (and error-prone) diffing, copy and pasting and so on, Daniel wrote a small perl script called uplang, it's located in the tools directory of your local rockbox-SDK (see DocsIndex on how to get such a build invironment).
Note: If you don't have or want a build environment, it should be possible to download the script to your pc and do it all without the build environment. Get a perl interpreter if you don't already have (on windows), for example ActivePerl
So be sure you can start the uplang-script either way, or opt for the hard way by doing it all yourself.
Preparation every time you update
The translation is always done "from" english, so english.lang is the master file. Monitor this file if you want to be sure to keep "your" language up to date.
The only one step of preparation you have to do every time you want to update "your" language is to run that script:
Bring yourself to the /apps/lang/-directory (or to the directory where english.lang and yourlang.lang reside if you work without build environment). Don't forget to update the file (cvs up english.lang or just a fresh download). Start the uplang-script with the following line:
../../tools/uplang english.lang yourlang.lang > newyourlang.lang
This assumes you are working "from" english, as usual, your outdated language file is called yourlang.lang and you want to get the merge to newyourlang.lang.
Now that uplang has merged the new changes from english to newyourlang.lang, you can go ahead with the actual work of translation, by opening the file in your favourite text editor.
The lang file format
I'm afraid we have to look into the format of lang files now. Every string needed in rockbox has a voice clip, this is why we can call such a pair a "resource". Every resource has absolutely unique identifier (called id), it has a description that tells you the context so you can select the wording (called desc), it has the original english string (called eng), it has a string specially for the voice clips (called voice) and it finally has the string in your language (called new).
I'm not yet sure (maybe someone who knows that detail can edit this article in this point) about how the voice-string looks like. I think this is only needed to be filled if you want that the voice clips says something else that the new-string is.
When updating a language, you are asked to solely change the new and voice string. changing id, eng and desc will either break-up everything or turn the subsequent update job into real pain.
Comments start with the hash-sign ('#', also called pound key in english; raute, viereckchen, lattenkreuz in german; or 'kanalgitterchen' in austrian. no joke, but funny :-) )
The translation
Mainly said, any ressource that needs attention has a '###'-comment. I will now list the 'scenarios' I know and how I think they have to be handled.
Deprecation
If a string is not needed anymore, it's not allowed to delete it in the master file, therefore, they are marked by writing "DEPRECATED" to the description. The todo-comment that will appear in the file your editing is "### Description changed! Previous description was:", followed by the OLD description line. This is by far the most stupid work to do when updating language files. I suppose this could be hacked to the uplang-tool. Example:
id: LANG_MUTE_ON_PLAYER
### Description changed! Previous description was:#
### "displayed when mute is on"
desc: DEPRECATED
### English phrase was changed! Previous translation was made on:
### "Mute ON"
eng: ""
voice: ""
new: "Son coupé"
A deprecated string is not needed anymore. As you can see, uplang already killed the eng-string and wrote down the new desc-string. All you have to do is to kill the new-string and remove the todo-comments. Example:
id: LANG_MUTE_ON_PLAYER
desc: DEPRECATED
eng: ""
voice: ""
new:
Omiting the the quotation marks even saves space.
Added Strings
If a new string has been found in english.lang, uplang will prepare a resource for you, so you only have to remove the todo-comment and translate the string. Example:
id: LANG_STEREO_WIDTH
desc: in sound_settings
eng: "Stereo width"
### Not previously translated
voice: "Stereo width"
new:
I'm not sure yet (as stated before) how to handle the voice-string. I think I don't need to explain the result of the translation job of this :-)
Translation style
The translation should feel as correct as possible to non-English speakers. This means that you should follow the rules of the language you're translating to, and not try to imitate the English version. For example with capitals, you should not capitalise anything other than what would be done if you were writing the text from scratch. Also try as much as possible to avoid using English words, as tempting as it may be, unless it's very commonly known and in daily use in your language (and not just among tech-interested people).
Your main work is done, if you can't find any '###'-comment anymore :-)
Now, go ahead and see if you did a mistake before posting your file (better than a patch) in the patch tracker on sourceforge.
Be sure to drop a line on the mailinglist after that so your updated file will get to the cvs as soon as possible. Whould be a bummer if somebody else would be doing the same work a week later.
Safety checks
Just for safety, I do a few checks. I use a file differ (BeyondCompare, will be avaiable for linux too in a while) for this.
- check: comparing the newyourlang.lang to yourlang.lang. This allows you to see WHAT you changed, just in case you did a big mistake.
- check: comparing the newyourlang.lang to english.lang. These files should only differ in new-strings and comments.
- check: binlang: This is the name of the tool that is used withtin the deployment process to make binary files (yourlang.lng) out of ressource file. It's located in the same tools directory than uplang, so you know where to find it. Its use is as easy as the uplang script: ../../tools/binlang english.lang yourlang.lang yourlang.lng
If binlang does not complain about anything, then this does mean that you didn't do a big mistake
- check: the experiment on oneself: copy the yourlang.lng to your rockbox (/.rockbox/lang), switch the language, and try it out.
Current status
As of 02 Sep 2005, the current status of the translations is the following:
Language | Untranslated strings | Percent translated |
Czech | 0 | 100.00% |
Dansk | 0 | 100.00% |
Deutsch | 0 | 100.00% |
English | 0 | 100.00% |
Finnish | 0 | 100.00% |
Francais | 0 | 100.00% |
Greek | 0 | 100.00% |
Hebrew | 0 | 100.00% |
Islenska | 0 | 100.00% |
Italiano | 0 | 100.00% |
Nederlands | 0 | 100.00% |
Norsk | 0 | 100.00% |
Svenska | 0 | 100.00% |
Galego | 21 | 96.13% |
Espanol | 46 | 91.53% |
Russian | 46 | 91.53% |
Wallisertitsch | 71 | 86.92% |
Polski-ascii | 173 | 68.14% |
Polski | 173 | 68.14% |
Slovenscina | 181 | 66.67% |
Romaneste | 227 | 58.20% |
Bulgarian | 255 | 53.04% |
Turkce | 279 | 48.62% |
Portugues | 288 | 46.96% |
Afrikaans | 319 | 41.25% |
Graphs
Translation status in Rockbox 2.4
Translation status in current CVS
Revision r1.33 - 04 Sep 2005 - 12:18 GMT - JonasHaeggqvist Parents: DocsIndex
|
Copyright © 1999-2005 by the contributing authors.
|
|
|